Subject: Questions about the HPR spec

From: [email-masked] (Matthew Finlayson)
Date: Wed, 13 Apr 94 18:18:23 BST

After reading through the HPR specification we have a few questions on the
design and on the design choices made. Would someone at IBM like to comment
on them?

1) SAPs (6.3.2)

The HPR spec explains that the decision to use a new SAP to transmit HPR LAN
traffic was taken primarily for reasons of product performance. Could you
expand on the reasons for this choice?

A simpler option would have been to send the HPR traffic in Unumbered
Information (UI) frames on the standard APPN SAP. This would have avoided the
rather untidy need to communicate the number of the HPR SAP down to the DLC
layer after XID exchange - a piece of protocol which is very LAN specific.

2) Long-lived RTP Connections (9.2.6.1)

I'm not sure that I follow the justification for having long-lived RTP
connections for Route-Setup between HPR Tower nodes (rather than sending
route-setup messages in FID2 packets as will be done if an HPR Base node
is involved).

The spec (in 9.2.6.1) suggests that this may have been done to permit HPR to
run over links without any link-level error recovery at some time in the
future. However, the protocol for Link Activation (6.2) in its discussion of
set-mode signals and especially the need for Link failure detection (6.4)
suggest that this will not be possible.

There are no obvious advantages for using RTP connections to transmit route-
setup messages since the normal RTP gains (end-to-end error recovery, fast
intermediate session routing) become irrelevant for a single hop route, whilst
HPR advantages such as path-switch are explicitly precluded due to the nature
of the long-lived connections. On the other hand, keeping a RTP connection
open for every HPR Tower-Tower link will tie up unecessary resources at both
ends and make the link-activation and route-setup protocols harder to
implement.

3) Boundary Function impact on CP-CP Sessions (10.2)

A minor point - this section of the spec seems to be rather confusing and
inaccurate. It suggests that protocol conversion (between FID2 and FID5) will
be done for CP-CP session traffic. The reality is that the traffic passing
between HPR and APPN subnets will reach the appropriate CP component and be
forwarded on a different session altogether.

Perhaps this section should be either rewritten or perhaps removed altogether.

4) Timescale for the next HPR spec update

Are you able to give us any idea when we might see the next version of the
HPR spec? In Ray Bird's email of 18th January he wrote

>  * Recent changes to the format of the CV4680 have occurred such that
>  * the TG type field is no longer used to indicate HPR capability
>  * (these changes will be reflected in the next version of the document).

suggesting that significant changes may have been made to the specification
since it was last published in September 1993.

==============================================================
Matthew Finlayson                   Data Connection Limited
([email-masked])                  Telephone: +44 81 366 1177
                                    Fax:       +44 81 367 8501
==============================================================